Documentación de los requisitos

Introducción

En la esencia de la ingeniería de los requisitos está la documentación de los requisitos de una manera consistente, accesible, revisable y comprensible.

Encontramos tres niveles en la documentación de un nuevo producto:

Los requisitos de negocio se suelen recoger en un documento de visión y alcance.
Los requisitos de usuario se suelen representar como casos de uso e historias de usuario.
La descripción detallada de los requisitos funcionales y no funcionales. Se almacena en la especificación de requisitos de software (SRS).

Especificación de requisitos de software (SRS)

El documento de requisitos de software o especificación de requisitos de software (ERS, o SRS por sus siglas en inglés, software requirements specification) consiste en una recopilación documentada y estructurada de todos los requisitos del sistema, y es un comunicado oficial de lo que debe implementar el equipo de desarrollo.

Audiencia de un SRS

La documentación de requisitos tiene una audiencia variada, por lo que debemos cuidar los aspectos comunicativos del documento. Debe ser un compromiso entre la claridad que esperan los clientes y usuarios , y el nivel de detalle requerido por los ingenieros.

También debe incluir información sobre la posible evolución de los requisitos para ayudar a los diseñador a ser muy restrictivos y a los ingenieros a comprender como adaptar el sistema ante nuevas necesidades.

Perfil de audiencia		Necesidades
	Clientes y usuarios	Expresan sus necesidades y revisan el documento comprobando que lo incluido es correcto, ayudando a detectar posibles cambios.
	Gestores del proyecto	Emplean el documento para poder planificar el desarrollo y determinar los recursos y el tiempo necesarios para su construcción.
	Ingenieros del proyecto	Usan los requisitos para comprender las características del sistema que deben desarrollar.
	Ingenieros de pruebas	Emplean la especificación para definir las pruebas de validación.
	Ingenieros de mantenimiento	Utilizan el documento para comprender el sistema y las relaciones entre sus componentes.

Propiedades de un SRS

Comprensible para todas las partes.
Correcto: contener solo los requisitos necesarios.
No ambiguo: una única interpretación, los términos con varias posibles interpretaciones hay que recogerlos en un glosario.
Completo: todo el sistema especificado.
Consistente: no hay conflictos entre los requisitos.
Verificable: todo requisito es verificable objetivamente.
Modificable: facilidad para introducir cambios.
Trazable: Todos los requisitos han de ser rastreables hacia delante y atrás.
Anotada con importancia y estabilidad.
Independiente del diseño y de la implementación: no ha de ser prescriptivo (evitar "habrá un botón", "habrá un menu"...).

Documentación en lenguaje natural

Los requisitos se pueden documentar de muchas maneras. En la práctica se emplea una combinación de redacciones en lenguaje natural y el empleo de modelos, donde el enfoque de una compensa las limitaciones de otra.

El lenguaje natural es la forma de documentación más empleada.

Presenta la ventaja de que ningún stakeholder tiene que aprender una notación específica, pero tiene el problema de que puede presentarse ambiguo, pudiendo resultar difícil distinguir las distintas perspectivas.

Para evitar algunos de los problemas del lenguaje natural, es habitual utilizar plantillas de redacción, que son modelos de la estructura sintáctica los requisitos individuales.

EARS: Easy Approach to Requirements Syntax

EARS: (Easy Approach to Requirements Syntax, aproximación sencilla a la sintaxis de requisitos), es un método para escribir requisitos que se apoya en un conjunto de definiciones y reglas, facilitando la homogeneidad de la especificación.

EARS define un conjunto de reglas y un total de 5 plantillas.

La sintaxis genérica para cualquier requisitos es la siguiente:

[precondición] (opcional): se utiliza para describir las condiciones en las cuales se puede invocar el requisito.
[evento de activación] (opcional): indica un suceso que desencadenará el comportamiento declarado.
el <nombre del sistema> DEBERÁ (obligatorio)
<respuesta del sistema> (obligatorio): es el comportamiento que se espera necesariamente del sistema, dada la precondición inicial y el suceso desencadenante.

Si el medicamento solicitado se encuentra en stock, cuando el usuario realice la búsqueda de un medicamento, el sistema deberá mostrar un listado de todos contenedores de ese medicamente que se encuentran en stock.

Solo si la precondición y el evento son ciertos se desencadenará el comportamiento esperado.

Esta sintaxis se especializa para cinco tipos de requisitos:

Requisitos ubicuos: son los que no tienen precondición ni evento de activación, y por tanto están siempre activos.

el <nombre del sistema> DEBERÁ <respuesta del sistema>
Ejemplo: El sistema de control DEBERÁ prevenir que el motor alcance velocidades superiores a los 120km/h.
Requisitos dirigidos por eventos: son iniciados cuando un suceso es detectado.

CUANDO [precondición] <evento de activación> el <nombre del sistema> DEBERÁ <respuesta del sistema>
Ejemplo: CUANDO el piloto envíe la señal de ignición continua, el sistema de control DEBERÁ activar el modo de ignición continua.
Comportamientos no deseados: describen cualquier tipo de situación que es preferible que no suceda (fallos, perturbaciones...).
A menudo estos requisitos se omiten, siendo una fuente de problemas.
Se utiliza una sintaxis derivada de la anterior, empleando las palabras SI y ENTONCES

SI [precondición] <evento de activación>, ENTONCES el <nombre del sistema> DEBERÁ <respuesta del sistema>
Ejemplo: SI se activa el indicador de fallo de cálculo de velocidad, ENTONCES el sistema de control DEBERÁ utilizar la velocidad de seguridad.
Requisitos dependientes del estado: son aquellos que tienen sentido cuando el sistema se encuentra en un determinado estado.
En este caso se utiliza la palabra MIENTRAS para comenzar el enunciado y la precondición es obligatoria.

MIENTRAS <precondición> , el <nombre del sistema> DEBERÁ <respuesta del sistema>
Ejemplo: MIENTRAS el avión este volando, el sistema de control DEBERÁ mantener el flujo de combustible en el motor.
Características opcionales: son aquellos requisitos aplicables solo en sistemas que incluyen una característica particular.
En este caso se utiliza la palabra DONDE para comenzar el enunciado y la precondición y una característica son obligatorias.

DONDE <precondición y característica> , el <nombre del sistema> DEBERÁ <respuesta del sistema>
Ejemplo: DONDE el sistema de control incluya una función de protección contra el exceso de velocidad, el sistema de control DEBERÁ comprobar la disponibilidad de la función de protección contra el exceso de velocidad antes de permitir el despegue del avión.

Requisitos de calidad

Los requisitos de calidad son una parte importante de los requisitos no funcionales de un sistema.

Podemos dividir los requisitos de calidad en dos categorias:

Calidad externa

La calidad externa es la que solo es apreciable ejecutando el producto, y es la que más claramente percibe el usuario.

Atributo de calidad externa	Descripción breve y «ejemplo»
Disponibilidad	Capacidad del sistema para ofrecer servicios cuando y donde se necesitan. «El sistema deberá estar disponible al menos el 99% del tiempo entre semana, entre las 6:00AM yla media noche, y al menos el 95% del tiempo del resto de los días y horas».
Instalabilidad	Facilidad para instalar, desinstalar y reinstalar una aplicación. «Un nuevo usuario no entrenado deberá ser capaz de instalar el producto desde cero empleando un tiempo medio de 10 minutos». «La instalación del producto en un servidor requerirá permisos de administrador».
Integridad	Capacidad del sistema para protegerse de inexactitud y pérdida de datos. «El sistema deberá comprobar diariamente que los ejecutables de la aplicación no han sido modificados por la adición de código externo».
Interoperabilidad	Capacidad del sistema para intercambiar información con otros sistemas y componentes. «El sistema de seguimiento de productos químicos deberá ser capaz de importar archivos válidos desde ChemDraw (versión 13.0 o posterior) y MarvinSketech (versión 5.0 o posterior)».
Rendimiento	Con qué rapidez y predictibilidad responde el sistema a eventos. «El navegador web deberá mostrar completamente la porción visible de una página web en pantalla empleando una media de 3 segundos o menos cuando se utiliza una conexión a Internet de 30 Mb/s o más rápida».
Confiabilidad	Con qué probabilidad el sistema se ejecuta con normalidad antes de fallar. «El tiempo medio entre fallos del sistema de procesamiento de analíticas no será inferior a 30 días».
Robustez	Cómo de bien se comporta el sistema en condiciones de operación anómalas. «Si el editor de imágenes falla antes de que el usuario haya guardado los cambios, entonces el editor de imágenes recuperará los contenidos del archivo que se estaba editando tal como estaba a lo sumo un minuto antes de que se produjera el fallo la siguiente vez que el usuario abra la aplicación».
Seguridad	Capacidad del sistema para proteger de daños a sí mismo o a su entorno. «El sistema de control del microondas sólo permitirá el inicio de un proceso de cocción cuando la puerta del horno esté cerrada».
Protección	Capacidad del sistema para protegerse ante accesos no autorizados. «El sistema bloqueará la cuenta de un usuario que haya tenido 5 intentos de conexión fallidos en el intervalo de 5 minutos».
Usabilidad	Facilidad de aprender, recordar y utilizar el sistema para las personas. «El 95% de los usuarios que han usado el producto antes serán capaces de realizar un nuevo pedido correctamente necesitando un periodo de entrenamiento de un máximo de 10 minutos».

Calidad interna

La calidad interna está relacionada con la calidad del propio código, su documentación y diseño, por ello interesa más al equipo de desarrollo.

Las características de calidad interna afectan a la calidad externa.

Atributo de calidad interna	Descripción breve y «ejemplo»
Eficiencia	Capacidad del sistema para aprovechar eficientemente los recursos. «La aplicación móvil no consumirá en ningún momento más del 30% de la capacidad del procesador ni ocupará más de 2GB en memoria».
Modificabilidad	Facilidad para mantener, cambiar, mejorar y reestructurar el sistema. «Los métodos de las clases del producto no contendrán bucles con más de 2 niveles de anidación».
Portabilidad	Facilidad para hacer funcionar el sistema en otros entornos operativos. «El usuario del navegador deberá ser capaz de importar y exportar sus marcadores desde y hacia los siguientes navegadores: Firefox (versión 20.0 y posteriores), Chrome (versión 29.0 y posteriores) y Safari (versión 5.1.10 y posteriores)».
Reusabilidad	Facilidad para utilizar los componentes del sistema en otros desarrollos. «El desarrollo del subsistema de gestión de pacientes deberá realizarse utilizando al menos el 90% del código del sistema actual de gestión de pacientes».
Escalabilidad	Facilidad para hacer crecer el sistema y dar servicio a más usuarios, transacciones, etc. «El sistema automatizado de ayuda al cliente deberá ser capaz de aumentar el número de peticiones procesadas de 50 llamadas por minuto a 150 llamadas por minuto en el plazo de 2 horas».
Verificabilidad	Facilidad para que los desarrolladores e ingenieros de pruebas puedan comprobar la calidad del sistema. «Cada uno de los métodos de las clases del módulo de procesamiento de pedidos tendrá asociadas al menos dos pruebas unitarias durante el diseño de las pruebas».

by Jose Manuel Pinillos